1. Field of the Invention
This invention relates generally to an improved object management system for tracking, cataloging, and managing data and code modules; and, more specifically, to an object management system and method for using objects storing meta-data to model a reusable group of code of data modules, and to further model the external interfaces presented by the group of code and data modules, the system being used to manage and to analyze the reusable group of code and data modules prior to performing renovation or migration operations on any of the code or data modules included in the group.
2. Background of the Invention
Many of today""s software solutions are being designed using an object oriented approach. According to this methodology, a design is broken into code and data modules wherein each module is tailored to perform a discrete function on data to which it is passed. If each module is designed to accomplish the function in a generalized, versus a task-specific, way, the modules may potentially be reused to solve a different task. Using this type of object-oriented approach, a large library of modules can be developed which may be mixed and matched to solve a variety of problems.
Using object oriented design methodology, each reusable code or data module has predefined relationships to other modules. As a simple example, consider a program module that includes instructions that reference data in a table. The program module might be described as having a relationship to the table module of xe2x80x9creferencesxe2x80x9d. Within a large complex system, thousands of modules and module relationships may be defined. For more information on object-oriented design methodology, see xe2x80x9cObject-Oriented System Developmentxe2x80x9d by Dennis de Champeaux, Douglas Lea, and Penelope Faure, published by Addison Wesley, 1993.
Using an object-oriented coding approach, it is possible to develop new solutions using existing functional code and data modules. For example, some of the existing code routines that may apply to a banking system could be similarly applied to a mail-order catalog business. Re-using these pre-existing routines saves development and test time. Another way to re-use code and/or data components involves identifying groups of such modules to be migrated from a first processing environment to a second processing environment. This type of migration operation may require re-implementation of some or all of the code modules into a different coding language, for example, or may involve creating additional layers of code called xe2x80x9cwrappersxe2x80x9d to bridge the existing code interfaces to the new platform architecture.
A user may also want to identify a pre-existing group of code and data modules so that the particular identified group may undergo a renovation operation. Such operations are necessary to update code and data modules to accommodate changing requirements. A good illustration of this type of operation involves updating code modules to correctly handle dates occurring after Dec. 31, 1999. Another type of renovation effort is needed to allow software to handle the European Monetary Unit (EMU), or xe2x80x9cEuroxe2x80x9d, which will become the common currency within many European countries within the next few years. Still other types of conversion are necessary when porting software between two machines that do not use the same word sizes, or when porting code to a machine having an expanded addressing space.
In all of the above examples, identification of all of the code and data modules needed to form a coherent, integrated application may be a very difficult task. Modules often have complex interdependencies. For example, a program module may call multiple subroutine modules. Each subroutine module may make additional references to databases, tables, or other data structures. The interdependencies must be accounted to when deciding how to group modules for potential re-use. For example, assume a particular program is to be incorporated into a group of modules that can be used to calculate end-of-month bank statements. All related subroutine modules and data structures associated with the bank statement generation and which are referenced by the main program must also be added to the group of modules.
To aid in the development of reusable groups or xe2x80x9cpackagesxe2x80x9d of code and data modules, some system is needed to catalog the various interdependencies between these modules. This system would ideally include a user interface that would aid users in understanding the various code and data interdependencies, and would further aid in the selection of the necessary modules.
Additionally, once identification of a complete set of modules has been accomplished, that set should be eligible for reuse within other groups. Also, groups of modules should be cataloged and made eligible for re-use in the same manner lower-level modules are cataloged.
It is a primary object of the invention to provide an improved object management system for cataloging code and data modules for potential re-use;
It is another object of the invention to provide an object management system for aiding users in selecting a group of re-usable code and data modules that can be used as an integrated package to perform a given task;
It is still another object of the invention to provide an object management system which catalogs each of the code and data modules in the system for re-use using a respective object that stores meta-data describing the respective module;
It is yet another object of the invention to provide an object management system that is model-driven, and that uses objects storing meta-data to catalog each of the code and data modules in the system, wherein each of the objects are of a pre-defined object type as defined in the system model;
It is yet another object of the invention to provide an object management system having an interactive user interface for allowing users to selectively include or omit code or data modules from a reusable group of such modules based on generalized requirements;
It is still another object of the invention to provide an object management system whereby the inclusion of modules within a reusable group of modules can be specified using filters;
It is still another object of the invention to provide an iterative and interactive method whereby a user is capable of locating all re-usable modules included within an object oriented programming environment which are necessary to perform a desired task;
It is yet another object of an invention to provide a system for allowing a user to define groups of re-usable code and data modules, whereby each of the groups so created become available for re-use within other groups of re-usable code and data modules;
It is still another object of the invention to provide an object management system that is model-driven, and that supports the creation of hierarchical code and data packages by combining low-level code and data modules, wherein the hierarchical packages are formed according to package types defined in the model;
It is yet another object of the invention to provide an object management system that supports the creation of groups of reusable code and data modules, wherein the modules contained within a group may be migrated from a first data processing platform to another data processing platform as a functional unit;
It is yet another object of the invention to provide an object management system that supports the creation of groups of reusable code and data modules, wherein the modules contained within a group may be made accessible from external data processing environments through the creation of code wrappers;
It is still another object of the invention to provide an object management system that supports the creation of groups of reusable code and data modules, wherein the modules contained within a group may be operated on as a functional unit for purposes of performing code renovation operations;
It is another object of the invention is to provide a system for allowing various unrelated hierarchical modules, each consisting of low-level re-usable code and data modules, to be included within other hierarchical modules along with interconnecting interface logic included in low-level re-usable code and data modules; and
It is still another object of the invention to provide a system having object management tools that operate in a generalized manner on both low-level re-usable code and data modules as well as on hierarchical modules created from multiple low-level modules.
Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment and the drawings, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention.
The forgoing objects and other objects and advantages are provided in the current invention, which is a system and method for managing re-usable groups of software constructs, including groups of code and data modules. According to the preferred embodiment, each of the code and data modules is modeled by an object for storing data describing the respective code and data module. Relationships between the code and data modules are each modeled by a respective relationship between the objects modeling those code and data modules. A user interface is provided which allows a user to view objects and relationships existing between those objects. The interface further includes various tools for viewing the data stored by the objects, and which aids the user in understanding the interdependencies existing between the respective code and data modules modeled by the objects.
The system includes package creation means for allowing a user to identify packages of software constructs that are associated with a predetermined task. The packages are created to take into account all interdependencies between the included software constructs. That is, a given package includes all of the code and data modules that are necessary and sufficient to perform a given task. Once a package has been created, the identified software constructs can be made the target of a renovation operation, can be migrated to a new platform, can be transformed into a different programming language, or can be made callable from an external platform.
The package creation means operates by allowing a user to identify one or more software constructs that will form the starting point for the package definition. The objects for modeling this initially-identified set of software constructs are displayed via the user interface, along with any relationships between this set of objects and other objects. These relationships between objects are indicative of interdependencies existing between ones of the initially-identified set of software constructs and other software constructs. These relationships are used to identify a second set of software constructs that must be added to the package so that all necessary interdependencies are taken into account. The objects for modeling the second set of software constructs are displayed via the user interface, along with any relationships between this set of objects and other objects, so that the process may be repeated. In this manner, the user may recursively add software constructs to a package of software constructs in a manner that allows all interdependencies between code and data modules to be readily taken into account. When the user has completed the package definition process, all software constructs that are needed to perform a particular task will be included in the package.
According to one aspect of the invention, the user is allowed to select software constructs to be added to the package by defining a filter that is automatically applied against relationships existing between objects. This application of the filter either includes, or omits, objects from the group of objects defining the package of software constructs. Alternatively, the user is allowed to individually include or omit object relationships, and hence objects, to be added to the group of objects defining the package of software constructs.
After the complete package of software constructs has been identified for a given package using the iterative process discussed above, the inclusion of each software construct in the package is recorded. In the preferred embodiment, this is accomplished by creating a package object to model the package. The package object is similar to any of the objects for modeling a respective software construct, and stores data indicative of the software constructs included in the package. A relationship is created between the package object and each object that represents a software construct included in the package. Because the same mechanism that is used to model software constructs is applied to packages, the same user interface and associated tool set may be employed to understand interdependencies existing between software constructs and packages of software constructs. For example, before a particular code module is modified, the object modeling that code module, along with any associated object relationships, can be used to readily determine if the module is included in a package, and if so, whether the potential modification will affect the functionality of the package.
According to another aspect of the invention, external interfaces associated with a package of software constructs may be recorded using interface specifications that are stored in the package objects. Each of these interface specifications describes the external interface of the associated package. That is, an interface specification describes the input and output parameters associated with the package of software constructs in a manner that allows a user to readily understand the functionality provided by the package. This functionality can be readily determined without having to understand the complex interdependencies between the software constructs included in the package. Using the interface specifications, a user may search for software packages that perform desired functions, thus making it easier to reuse these packages to develop new applications. These interface specifications may also be used, for example, by component consumers and component producers to identify a requested software function.
According to yet another aspect of the invention, existing package objects may be used during the creation of still other package objects. That is, package objects may be created that model software packages that include other software packages. According to the preferred embodiment, this is represented by forming relationships between a respective package object and other package objects. This allows interdependencies between packages of software constructs to be recorded and managed. Any number of levels of hierarchy may be created within the package object definitions.
Still other objects and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description of the preferred embodiment and the drawings, wherein only the preferred embodiment of the invention is shown, simply by way of illustration of the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded to the extent of applicable law as illustrative in nature and not as restrictive.